When we copy/graft/prune, we split the entire work that needs to be done into batches that are meant to take roughly three minutes to avoid bloating the subgraph_deployment table. Pruning causes a very serious problem with that, and when that happens it can be crippling for the performance of the overall system.

The code that adjusts the size of the batch to hit that target tacitly assumes that the actual work is distributed linearly, i.e., if we ask for work covering 10,000 rows (going by vid), we are fine with getting fewer rows, maybe even just a handful, but this needs to be uniform: any 10,000 row batch needs to have roughly the same number of rows. Pruning breaks this assumption since in a pruned subgraph, the beginning of the subgraph (as determined by block numbers) will be much sparser than the later parts. In one case, this misled the estimation logic to eventually try and copy 160M rows since that's what the early part of the subgraph indicated could be copied in the three minutes, as the subgraph was pruned and the range of 160M row numbers only contained 128 rows in the beginning of the subgraph. After that, the subgraph was dense and copying 160M vid's would take many hours.

This PR removes the assumption that the relation between vid and actual rows is linear. It uses the histogram_bounds from pg_stats to build a piecewise linear function, and estimates the number of rows in a given vid range using that piecewise linear function (the Ogive in the code) Now, when we ask for a batch of 10,000 rows, the code will adapt to an uneven vid distribution and return different size vid ranges for different parts of the table.